Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[GAP-22] Invoice-based reputation system #47

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

johny-b
Copy link

@johny-b johny-b commented Feb 3, 2022

A description of the "invoice - based reputation system".
Nothing final here, just a description of the idea.

@johny-b johny-b marked this pull request as draft February 3, 2022 11:16
@johny-b johny-b self-assigned this Feb 3, 2022
@johny-b johny-b marked this pull request as ready for review February 3, 2022 16:05
@johny-b johny-b changed the title Invoice-based reputation model Invoice-based reputation system Feb 3, 2022
@rad9k
Copy link

rad9k commented Feb 8, 2022

I will not be present at next TC, thus I would like to leave some important feedback (I had a long call with JB about document)

  1. Assuming the inoices issuing / paying being present in blockchain history, the invoice based reputation is one amongst two reputation management solutions I would propose now to be used on Golem operationally.

  2. the Second solution is local reputation history being exposed by GAP-14 API by requestor/provider type actor meeting following criteria:

  • has a lot of interactions with providers (for requestor type actor)/requestors (for provider type actor)
  • someone (best: a lot of same type actors) is willing to trust the actor
  1. the local history GAP-14 API like solution has major drawback: it is not economy profitable to expose local history (unless we believe that evil actors will play nice with us becouse we expose it, need to evaluate mathematically with has greater game theory impact)

  2. the blochchain history exposed invoice based solution has one major draw back: it will work if evil action revard value distribution Is central around some point. in case of high evil action revard the system might be disturbed by it

  3. how to choose final reputation management solution to be working operationally in 2022: check "go to market" estimation for both solutions. need to think realistically in terms of "what actions in terms of presence and good will of given type of actors needs to happen to make this reputation management solution to effectively work and deliver expected knowledge to all the market actors"

@stranger80 stranger80 changed the title Invoice-based reputation system [GAP-22] Invoice-based reputation system Mar 7, 2022
@cryptobench
Copy link
Member

Minor comments from skimming through.

Perhaps we could clarify agent - Provider/Requestor
image

Agent again
image

Agents market strategy
I would add the market part, just so the community is aware. We refer to it as market strategy always
image

Typo in provider
image

@johny-b
Copy link
Author

johny-b commented Mar 14, 2022

Minor comments from skimming through.

Thx!
Next time pls comment on the attached .tex file. There is 1-1 correspondence between the files, .pdf is just a rendered version. This way you'll skip uploading printscreens and I'll skip looking for the right part :)

* Replaced all occurences of "agent" with "provider/requestor", to avoid
confusion
* Removed all references to the (temporarly?) abandoned "microeconomic
reputation" document
* Elaborated on the "debit notes instead of invoices" idea
* Few typos
@cryptobench
Copy link
Member

Minor comments from skimming through.

Thx! Next time pls comment on the attached .tex file. There is 1-1 correspondence between the files, .pdf is just a rendered version. This way you'll skip uploading printscreens and I'll skip looking for the right part :)

Thanks for the suggestion. I didn't think about it when commenting but i'll have it in mind for the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants